Prior to shipping an IC to an end user, the IC must be tested to determine whether it has been manufactured correctly and is fully operational. A variety of IC testers are available for such testing. Typically, an IC tester is a very large and expensive machine which is designed to precisely position the placement of logic signal transitions at very high speeds. Most testers are aimed at creating a “functional environment” for an IC. A functional environment is one which mimics the environment in which the IC will eventually be used, to thereby demonstrate that the IC will behave as expected in that environment. A tester which creates a functional environment for an IC is referred to as a “functional” tester.
A functional tester applies a series of “test vectors” to the inputs of an IC. A test vector is a critically timed cycle of events lasting a short period of time referred to as a “vector cycle”. Within a vector cycle, and at precisely calculated times, logic signal drivers in the tester apply stimulus to IC inputs. At the same or some precisely delayed time, logic signal comparators in the tester monitor responses at IC outputs. When many test vectors are executed sequentially, discrepancies between monitored and expected IC outputs, if any, are noted as IC failures. Failed ICs are then scrapped, and passed ICs are shipped to customers.
A vector cycle may last only a few nanoseconds, and a plurality of events may be timed within the cycle, with each event having a resolution in time as short as ten picoseconds. As technology continues to advance, there are increasing pressures for even shorter cycle times and finer event resolution. To complicate matters even more, functional tests are very difficult to prepare and may suffer from unknown fault coverage (i.e., unknown quality). Typically, functional tests for an IC must be created by those who designed the IC, and little automation can be used in the creation of the tests. While simulators can be used to predict how an IC will behave, simulators are often not the solution because 1) simulators often have limited fault modeling capability and, as a result, have a limited ability to determine how a test will react to “real world” faults, and 2) simulation is expensive and time-consuming, especially when generated tests are of an unknown quality.
An alternative or adjunct to functional testing is “structural” testing. Structural testing became of interest in the mid-1970's, and is discussed in detail in the paper of M. J. Y. Williams and J. B. Angell entitled “Enhancing Testability of Large-Scale Integrated Circuits Via Test Points and Additional Logic”, IEEE Trans. on Computers, vol. C-22, no. 1 pp. 46–60 (January, 1973), and in the paper of E. B. Eichelberger and T. W. Williams entitled “A Logic Design Structure for LSI Testability”, Proc. 14th Design Automation Conf., IEEE Pub. 77CH1216-1C, pp. 462–468 (June, 1977), which papers are hereby incorporated by reference for all that they disclose. Initially called “scan” testing, structural testing enables the testing of structures which are deeply embedded within an IC. Rather than testing the IC's internal structure by applying stimulus to the IC's inputs, structural testing involves shifting a series of test vectors into the core of an IC, and after each test vector is shifted in, launching the test vector and capturing a response. Each response is then shifted out of the IC. In this manner, a tester can verify that all of an IC's elements are present and operational. An assumption of structural testing is that if all elements are present and operational, then the elements will contribute to performing the greater and intended functions of an IC (e.g., adding, shifting, etc.), and the IC will function as designed.
FIGS. 6 and 13 illustrate conventional ICs which incorporate one or more scan chains for the purpose of enabling structural testing of the ICs. An IC which is designed for structural testing is commonly referred to as being “designed for test”, and therefore incorporates “design for test” (DFT) structures. The basic rules (i.e., DFT rules) for enabling structural testing of an IC are:                1. Implement the IC using synchronous clocked design (no asynchronous feedback).        2. In place of each register element (e.g., flip-flops) in the IC, insert a more complicated register element (i.e., a scan chain cell) having two modes of operation:                    a. A “normal mode” where the element works as a clocked memory element as required for the functionality of the IC; and            b. A “test mode” where the element behaves as a member of a scan chain (i.e., a serial shift register chain).                        3. Link the scan chain cells to form a scan chain and route appropriate signals (e.g., mode, shift and data I/O signals) to each of the cells.        
If desired, structural testing can be expanded to the board level. When designing a board, a designer can link signals of each IC at the board level (e.g., mode, shift and data I/O signals) to thereby expand structural testing to the board test level. A detailed discussion of various scan chains may be found in the paper of T. W. Williams and K. P. Parker entitled “Design for Testability—A Survey”, Proceedings of the IEEE, (Invited paper), vol. 71, no. 1, pp. 98–112 (January, 1983).
Once an IC has been made scan-testable, then its structure becomes logically equivalent to a combinational logic network surrounded by a rank of memory elements (i.e., the scan chain). Since test vectors can be shifted into and out of the memory elements of a scan chain, the elements become test resources that can 1) supply inputs to the combinational logic network, and/or 2) monitor outputs of the combinational logic network. Thus, the essentially intractable test generation problem for a sequential digital circuit of arbitrary complexity is reduced to the much simpler test generation problem for a combinational circuit, for which much automated technology exists.
Tests for a combinational circuit may be generated by an Automated Test Program Generator (ATPG) which is given the circuit description and a list of faults to be tested. Since an ATPG is typically designed to generate parallel test vectors (i.e., test vectors which can be applied to and received from the inputs and outputs of a combinational circuit), a serializer algorithm can be provided with both the parallel test vectors, and a description of the combinational circuit and scan chain, to thereby create a serial test program that can deliver the parallel test vector inputs to the combinational circuit via the scan chain. When a parallel test vector is in place, a normal clock pattern of the combinational circuit is then triggered for the purpose of launching the test vector into the combinational circuit. Finally, a response to the test vector is collected in elements of the scan chain and shifted out of the scan chain serially.